Skip to content

gh-153568: Pause the GC while converting the AST to Python objects - #153583

Open
pablogsal wants to merge 1 commit into
python:mainfrom
pablogsal:gh-153568-ast2obj-gc
Open

gh-153568: Pause the GC while converting the AST to Python objects#153583
pablogsal wants to merge 1 commit into
python:mainfrom
pablogsal:gh-153568-ast2obj-gc

Conversation

@pablogsal

@pablogsal pablogsal commented Jul 11, 2026

Copy link
Copy Markdown
Member

Building the Python object tree out of the C AST allocates thousands of container objects in a burst, which repeatedly trips the garbage collector into traversing the half-built tree. Those nodes cannot be part of a reference cycle until the conversion exposes them, so a collection during the conversion can never free anything of this tree. Pausing the collector around the conversion (restoring the previous state, so a user-disabled GC stays disabled) removes those wasted traversals.

Benchmark (running ast.parse over 8 of the largest stdlib files, 1.3 MB, 20 times per run; pinned cores):

build time per run speedup
main 133.6 ms
this PR 120.5 ms 1.11x faster

Executed instructions (stable under machine load, perf stat) drop by 5.6%.

Freshly converted AST nodes cannot be part of a reference cycle yet, so
collections during the conversion only pay to traverse the half-built
tree without ever freeing any of it.
Comment thread Parser/asdl_c.py
// so a garbage collection while building them cannot free anything of
// this tree and only pays to traverse its half-built nodes. Pause the
// collector while the conversion runs.
int gc_was_enabled = PyGC_Disable();

@maurycy maurycy Jul 17, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My, probably naive, question here is what about free-threading?

There seems to be a single global (per interpret) state:

int
PyGC_Enable(void)
{
GCState *gcstate = get_gc_state();
return _Py_atomic_exchange_int(&gcstate->enabled, 1);
}
int
PyGC_Disable(void)
{
GCState *gcstate = get_gc_state();
return _Py_atomic_exchange_int(&gcstate->enabled, 0);
}

static GCState *
get_gc_state(void)
{
PyInterpreterState *interp = _PyInterpreterState_GET();
return &interp->gc;
}

For example: a thread disabled GC (in the window between here) but the parser would enable it again?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes this will always be racy because is currently not possible to know if this was us or someone else doing it. This is something we need to consider when reviewing this optimization

@maurycy maurycy Jul 18, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe this is a more general problem?

Quick ripgrep reveals:

/* We need to call gc.disable() when we'll be calling preexec_fn */
if (preexec_fn != Py_None) {
need_to_reenable_gc = PyGC_Disable();
}

if (need_to_reenable_gc) {
PyGC_Enable();
}

In reverse, maybe even more places would gain from disabling changing the default GC behaviour (disabling it?).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants